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SECTION I. 



OVERVIEW 



Receipting and' disbursing child support payments is a major activity in 
courts and child support enforcement offices across the country. The 
traditional approach to this process is to receive paper checks from 
obligors, record the payments, and send paper checks to obligees. In 
light of the growing availability and use of electronic funds transfer 
technologies, the traditional approaches to handling paper checks may be 
unnecessarily costly to child support agencies and courts. The exclusive 
use of paper checks may also unnecessarily delay movement of payments from 
obligors to obligees who need those funds to pay for their children's 
expenses. 

This report is a part of the Iowa-Nebraska Electronic Funds Transfer 
Project. The purpose of the project is to explore the possibilities of 
using electronic funds transfer (EFT) technology and applications to 
increase the speed and efficiency with which child support payments reach 
obligees. Earlier reports produced as a part of this project gave an 
introduction to EFT technologies and their potential applications to child 
support collection and distribution. Other reports provided a detailed 
description of the current receipting and disbursing procedures. This 
report furthers that purpose by prescribing a design for a pilot project 
to test and evaluate the cost effectiveness of the electronic funds 
transfer applications identified as having potential for improving 
payments handling. 

This pilot project design report includes functional specifications for 
the systems necessary to accommodate the selected EFT applications. The 
report also includes a workplan outlining the steps necessary to implement 
the applications and, finally, describes the costs and benefits 
anticipated from their implementation and operation. Sample authorization 
forms for use in the project were submitted in an earlier report. 

The processes included in this pilot project design include the following 
EFT applications to child support collection and distribution: 

Oirect Oeposit of Income Withholding. A growing percentage of child 
support payments are being made in the form of income withheld from 
employee's paychecks. Currently employers send a single check each pay 
period to the child support agency for all obligors/employees for whom 
they are required to withhold child support payments. If there is mora 
than one obligor involved, the employer sends a list of the obligors and 
the amounts of child support being remitted for each obligor with the 
single check to the receipting entity. The process of receipting income 
withholding payments for multiple obligors is one of the most labor 
intensive elements in Iowa's child support collection. 

This application of EFT technology for the income withholding process 
utilizes employers' existing systems for direct deposit of payroll to 
submit child support payments. The process would require the employer to 
add an additional payment account number into the payroll system used to 
handle direct deposits. Each time payroll was processed, an ACH file 
would be created by the employer as it normally is for the direct deposit 
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process. The employer's financial institution would initiate an ACH 
transmission that would result in a credit to the CSC's account. The CSC 
would be advised of the credit for each obligor on a daily statement or by 
electronic data transmission. 

For the employer, direct deposit eliminates the time and expense of 
preparing and sending a check and its associated payment listing to the 
CSC. Oirect deposit would also speed the deposit process and reduce the 
workload for the CSC staff. 



Automatic Withdrawal from Obligor Checking Accounts. This EFT application 
is already available to obligors paying through Iowa's CSC. Daily, the 
CSC submits a computer tape through the bank to effect the transfer of 
funds from the relevant obligor's account to the state's account. At the 
time the tape is created, the state's computer system also creates an 
entry of the receipt to the obligor's account, making entry of a receipt 
to the ICAR system unnecessary. 

The primary benefit of this process is the reduced manual effort in 
processing incoming paper checks. The obligor benefits by not having to 
take the time or expense to mail a check. Obligees benefit by receiving 
child support faster and more regularly. 



Direct Deposit to Obligee Checking Accounts. Iowa's CSC is already 
capable of creating a daily computer tape that results in an ACH network 
transfer of funds from their account to obligees' accounts. Obligees 
enjoy the advantage of receiving payment earlier and of avoiding the need 
to take or mail their child support payment to the bank. The benefit to 
the CSC is that a direct deposit potentially eliminates the cost of 
producing and mailing state warrants. 



Charges to Obligor Credit Card Accounts. Accepting credit card payments 
from obligors has as its primary advantage the ability to offer obligors 
another means of remittance that may increase the likelihood of 
consistent payment. For prearranged periodic charges, the agency would 
periodically submit to the processor or bank an electronic file of 
accounts for credit card charges. Similar to automatic withdrawals, the 
CSC deposit account would reflect the payments received within a few days 
after the data transmission was created. 



Additional features and options for each of these EFT applications for 
child support collection and distribution are described in the systems 
specification section. More information on costs and benefits is provided 
in the cost benefit summary section. 
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SECTION II. 
SYSTEM SPECIFICATIONS 



INTRODUCTION 



This document provides functional specifications for the systems necessary 
to implement EFT applications for child support collection and 
distribution in the state of Iowa. It provides a high-level description 
of the functional requirements of new systems to be designed or purchased 
as well as of necessary modifications to existing systems. 

It is anticipated that more detailed design documents would follow this 
document before programming was begun. This document is intended to 
provide sufficient background to allow a systems analyst to move forward 
with general design and detail design phases with little additional 
orientation. Additional description of the project and current child 
support collection procedures have been included to meet this aim. 

As outlined in the document, some choices remain in deciding exactly how 
the system should be implemented. Some choices are a matter of service 
policy while others are a matter of cost. Still other choices depend on 
the capabilities of the service provider chosen for processing the ACH and 
credit card transactions and the capabilities of the financial institution 
receiving direct deposits from employers. 



< 
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DIRECT DEPOSIT OF EMPLOYER INCOME WITHHOLDING 



GENERAL INFORMATION 

Nature of. the System 

A growing percentage of child support payments are being made in 
the form of income withheld from employee's paychecks. Currently 
employers typically submit a single check each pay period for all 
obligors/employees for whom they are required to withhold child 
support payments. If there is more than one obligor involved, 
the employer sends a list of the obligors and the amounts of 
child support being remitted for each obligor with the single 
check to the receipting entity. The process of receipting income 
withholding payments for multiple obligors is one of the most 
labor intensive elements in Iowa's child support collection 
process. 

This system would utilize existing employers' systems for direct 
deposit of payroll to submit child support payments. 

Environment 

Iowa and Nebraska are being used as case studies to assess the 
applicability of EFT technologies to child support. This 
document is sponsored by the Iowa-Nebraska Electronic Funds 
Transfer Project. 

OVERVIEW 

Purpose and Scope of the System 

Income withholding refers to an obligor's earnings being withheld 
by his/her employer and sent to the CSC as a child support 
payment. Income withholding is required by federal law for IV-0 
cases in arrears by an amount equal to or exceeding the support 
payable for one month. In addition to those obligors required by 
law to pay child support through income withholding, a few 
obligors voluntarily pay through income withholding. 

This application of EFT technology for the income withholding 
process utilizes employers' existing systems for direct deposit 
of payroll to submit child support payments. The process would 
require the employer to add an additional payment account number 
into the payroll system used to handle direct deposits. Each 
time payroll was processed, an ACH file would be created by the 
employer as it normally is for the direct deposit process. The 
employer's financial institution would initiate an ACH 
transmission that would result in a credit to the CSC's account. 
The CSC would be advised of the credit for each obligor on a 
daily statement or by electronic data transmission. 



Employers have multiple methods of creating an ACH record for 
child support payments. Many will use a standard payroll direct 
deposit system that distributes the employee's pay into multiple 
deposit accounts by ACH transmission. Others may create a 
special deduction system that deducts the amount from the 
employee's pay and creates an ACH record to deposit the funds 
into the CSC's deposit account. 

The scope of this document is to define the necessary processes 
that would need to be implemented by the CSC in order to receive 
a payment through the ACH system. This document assumes that the 
employer will create an ACH record by whatever means is most 
practical and only addresses the methods of receipting the 
payments into the CSC system. 

Performance Objectives 

Employers: 

Direct deposit eliminates the time and- expense of preparing and 
sending a check to the CSC. Similarly, direct deposit eliminates 
the time and expense of preparing and sending to the CSC a 
listing of employees for whom the payment should be applied. 
Once the employee's child support payment is set up on the 
payroll system, the employer need take no further action unless 
the child support amount is modified. 

CSC: 

Direct deposit payments would be credited to the CSC's account 
precisely on the payroll date avoiding the current five days or 
so that elapse while the employer's payroll personnel prepare the 
list of employees, write the check and send the payment through 
the mail to the CSC. Automatically depositing these funds would 
also save the staff time required to physically deposit these 
items. The process of key-entering the account number and 
receipt amount may still be needed. However, it may be possible 
for the CSC to receive deposit information in an electronic 
format from the bank. 

Existing Methods and Procedures 

Currently for income withholding cases, employers withhold funds 
from employee paychecks and remit the funds to the CSC each pay 
period, or at least once per month, as required by the court 
order. Most employers send a single check with a listing of 
amounts to be applied for each employee. This is usually a 
manual process on the part of the employer performed a few days 
after the end of the pay period; employers are required to make 
payment within ten days after the payroll date. The CSC must 
then key-enter these items into the ICAR system. Since coupons 
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are not returned with employer payments, the efficiencies made 
possible by the remittance processing equipment do not apply to 
these payments. The remittance processor is used to encode, 
endorse, and microfilm these checks, but does not eliminate the 
need to manually enter the receipt. 

Proposed Methods and Procedures 

For each employee on income withholding, the employer (or their 
payroll processor) would enter an additional payment account 
number into the payroll system used to handle direct deposits. 
Many employers who have direct deposit systems have the ability 
to make deposits into more than one account for each employee. 
The added account number would be that of the CSC. The obligor's 
case number or social security number would also need to be added 
to the employer's record. 

Each time the payroll was processed, an ACH file would be created 
by the employer either as a part of the direct deposit o 
or as a part of a deduction process. 

The ACH file would be transmitted to the employer's servicing 
financial institution. That financial institution would initiate 
the ACH transaction that would result in the CSC's account being 
credited with the specified amount. The CSC's account would be 
credited on the second working day following the employer's 
transmission to their financial institution. Since most 
employers begin the process early enough for employee's accounts 
to be credited on the day payroll checks are issued, this would 
result in the CSC being credited with the receipt on the same day 
that, in the current process, the employer is mailing the child 
support check to the CSC. 

The Treasurer's office would normally receive a record of the 
transactions on its weekly account statement showing a separate 
payment for each obligor. Each item on the statement would 
include the payment amount, the employer's name, the transaction 
date and either the case number or the social security number for 
the obligor. The CSC could obtain a copy of the account 
statement from the Treasurer's office or directly from the 
financial institution. 

The CSC may require more complete information about the payments 
received, including such key elements as the obligor's name. The 
financial institution could provide the CSC with a daily listing 
of the complete ACH record information for each payment 
received. This listing could be delivered to the CSC in the form 
of a hardcopy report, a magnetic tape or a file transmission by 
PC or mainframe. 

The CSC would either manually enter the receipts into the ICAR 
system or electronically update the ICAR system with the file 
transmitted from the financial institution. 
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Summary of Improvements 

The primary benefit of this process for employers is that it 
eliminates the time and expense of preparing and mailing a check 
and a payment listing each payroll period. The child support 
reoei-pti^g entity benefits from not having to physically deposit 
the checks. The receipts would still have to be key entered from 
the bank statement by the receipting entity, unless an automated 
interface could be arranged. The obligee should receive child 
support payments sooner because the employer would time, the 
submission of the EFT data so that the deposit to the agency's 
account would occur on the date the check would normally be 
mailed by the employer. 

Summary of Impacts 

Hardware 

The ICAR system resides on an IBM-370 which uses OS/VS as 
the operating system. The mainframe system includes both 
tape drive and modem capabilities. Multiple personal 
computers operate in the CSC for support activity and some 
of these computers have modem capabilities. 

Each of the methods of receiving ACH files from the 
financial institution can be accomplished with existing 
hardware. This does, however, assume the periodic 
availability of a personal computer with a modem. 

Software 

The ICAR data base is developed in IDMS Cobol as the batch 
processing software with the on-line software written in 
AOSO. The Financial institution has four methods to provide 
the CSC with the obligor's payment information: 

transfer of data through RJE - mainframe computer to 
mainframe computer, 

transfer of data from personal computer to personal 
computer, 

transfer of data on tape for processing on mainframe 
computer, 

transfer of data on a report list. 

Software will need to be developed on either the mainframe 
or personal computer to format the receipting information 
for input into the ICAR system for the first three methods. 
The fourth method would utilize the existing process for 
manually entering receipts. 
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Operational 



Since this system will likely reduce the number of manual 
-entries being made by "CSC staff for obligor payments from 
employers, it should not increase staff workloads. 

Organizational 

This system should be managed by the CSC with staff that 
currently operates and reconciles the remittance processing 
system. 



REQUIREMENTS 
Functions 

This system will be required to perform the following functions: 

Receive payment information from the financial institution, 

Format payment information for input into the ICAR system, 

Report and reconcile activity. 

Receipt of payment information from the financial institution may 
be in several ways: 

Transfer of data from the financial institution's mainframe 
computer to the CSC's IBM-370 could be accomplished 
utilizing IBM 2780/3780 RJE Workstation software. The file 
would be transmitted at 9600 baud. The file transmitted to 
the CSC would contain an ACH formatted record containing 
detail on each obligors' payment that originated from an 
employer's payroll system which was deposited to the CSC's 
account. 

Transfer of data from the financial institution's personal 
computer to one of the personal computers that currently 
reside in the CSC would be accomplished by utilizing 
standard personal computer file transfer software (Xmodem). 
The file that would be transmitted to the CSC would contain 
an ACH formatted record containing detail on each obligors' 
payment that originated from an employer's payroll system 
which was deposited to the CSC's account. Once this file 
was received on the personal computer it would need to be 
transferred to the IBM-370 for formatting and input to the 
ICAR System. 

Transfer of data from the financial institution could occur 
on a magnetic tape. The magnetic tape would be processed at 
1600 BPI and would be hand delivered to the CSC for 
processing. The tape should be standard non-labeled. This 
tape would be read on the IBM-370 Tape Drive and the file 
loaded to disk for processing. The file would contain an 
ACH formatted record containing detail on each ob'igors' 
payment that originated from an employer's payroll system 
which was deposited to the CSC's account. 
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. The financial institution could provide the CSC with a 
hardcopy report containing a list of the ACH records that 
were processed on a daily basis. This report would then be 
" used by CSC staff members at existing CRTs to access the 
ICAR system and input each obligor's payment. 

Formatting of the ACH file containing payment information for 
input into the ICAR system may be accomplished in a couple of 
ways: 

A program could be developed to read each record in the file 
that was transferred from the financial institution and 
determine if the ACH record contained the case number or 
social security number in the 10 field (see Appendix A for 
location of ID field). Case numbers could be distinguished 
from social security numbers by having the employers add an 
alpha prefix to case numbers. If the ACH record contained a 
case number, a payment coupon could be printed and processed 
by the remittance processing system. 

If the ACH record contained a social security number in the 
ID field, an alternate access method into the case file 
would be necessary to identify the appropriate case number 
for that social security number and then print a payment 
coupon that would be processed through the remittance 
processing system. Where multiple case numbers were found 
for a given social security number, an exception would be 
noted on the daily posting report so manual entry could be 
made. This would require minimal modification of the ICAR 
system and could be an independent program. 

Another method of input into the ICAR system would be to 
format the ACH records into a file format similar to the 
remittance processing system file that is transmitted to the 
IBM-370 on a daily basis. The ICAR system would need to be 
modified to merge these records into the remittance 
processing file for input. This method would still require 
that a program be developed to interrogate the ICAR system 
for case information if the ACH record only contained the 
social security number rather than the case number. 

The system should provide sufficient reporting to allow 
reconciliation of the entries provided to the CSC by the 
financial institution with the ACH deposit that will be reflected 
on the CSC's daily transmittal letter to the Treasurer's office. 
The following reports will be a necessary component of this 
system: 

Input Detail Report 

The Input Detail Report will be a detail list of the 
entries on the ACH file that was transmitted from 
the financial institution. This report should 
provide a dollar summary of the entries on the file 
which should reconcile to the deposit made to the 
CSC account by the financial institution. 



- 9 - 



Daily Posting Report 

The Daily Posting Report should be produced from the 
reformat program which interrogates the ICAR system 
to validate the case numbers or locates case numbers 
for records which contain the social security 
number. This report should contain a detail list of 
the payments that will be applied directly to the 
ICAR system as well as a detail list of the 
exceptions which were not applied to the ICAR 
system. Examples of exceptions are multiple case 
numbers for a single social security number, invalid 
case number, invalid social security number, case 
number not found, case closed and payment amount 
exceeds remaining payment balance. Total and 
subtotal amounts should be included to reconcile 
with other reports. 

Coupon Production Report 

This report would be necessary if the system were 
implemented without direct input into the ICAR 
system. This report would actually be a form which 
simulates the existing payment coupons and would be 
printed from the information which would be the 
output from the reformat program. 

Performance 
Accuracy 

Employers must help identify the type of information the ID 
number field of the ACH record contains. An alpha character 
in the first position of the field would identify the number 
as a case number and distinguish it from a social security 
number. The system must be designed to reject any social 
security records that identify or point to multiple case 
numbers. This system should assume a one to one 
relationship for entries being made through the ACH. 

Flexibility 

The program which reformats the ACH file for input into the 
ICAR system should be be designed to accommodate other types 
of payments such as alimony payments, should these be 
collected through income withholding in the future. 

Inputs and Outputs 

Inputs 

Input into the system would be an ACH file transmitted by 
the- financial institution. Specific header information on 



- 10 - 



, the file would be determined by the selected financial 
institution. Detail records would be in two record formats. 
The first record would be the company batch header. The 
company batch header would be followed by all payments 
originating from the same employer. One or moire entry 
detail records follow each company batch headers. The 
following are the data elements associated with each type of 
record format: 

Company Batch Header 

Reference Appendix A for record format 

Entry Detail Record (PPD) 

Reference Appendix A for record format 

Output 

Output from the system would be the following: 

A file from the reformat program 
containing data elements similar to the 
remittence processing system files for 
input into the ICAR system 

All defined reports 

Failure Contingencies 
Backup 

The file transmitted from the financial institution should 
be backed up prior to running the reformat program. This 
will ensure that a processing failure will not require a 
re-transmission from the financial institution. The 
formatted file which will become input into the ICAR system 
should also be backed up prior to processing them as 
payments. 

Fall Back 

If for any reason the processing/reformatting system fails 
and ICAR is unable to accept an automated input, the Input 
Detail Report will contain sufficient information to 
determine appropriate case number so that payments may be 
. manually entered. 

If for any reason the financial institution is unable to 
transmit the ACH file to the CSC f the weekly account 
statement normally received by the Treasurer's office will 
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contain the following information which could be used to 
determine appropriate case numbers so that payments may be 
manually entered: 

Name of the Employer 

Company Entry Description (i.e. "Payroll") 
Amount of Payment 

Individual Identification Number (which will be 
either social security number or case number) 

Recovery and Restart 

The system should be designed to allow automated payments to 
be reversed in an automated environment. This means that a 
program should be developed to read the reformatted file 
which became input to the ICAR system and produce a 
cancellation for each payment. This would be necessary if 
for some reason the financial institution transmitted 
duplicate records to the CSC. 

Documentation 

The following documentation should be produced and become an 
inherent part of this system: 

Operations Manual containing instructions on receiving the 
ACH file from the financial institution, running the 
reformat program, producing reports, preparing the file for 
processing into the ICAR system, and all supporting 
documentation for fallback and restart/recovery procedures. 

User's Manual containing information on a detail level of 
all reporting, reconciliation procedures and exception 
processing. 

General Design and Detail Design documents which are 
produced to develop this system. 



OPERATING ENVIRONMENT 
Equipment 

IBM-370 Mainframe 

IBM Tape Drives 

Personal Computer 
Support Software 

IBM 2780/3780 RJE Workstation software 

File Transfer software for Personal Computer 
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Interfaces 

Transmission interface to financial institution 
Upload capability from personal computer to IBM-370 mainframe 
Controls 

The system should be designed to limit the possibility that a 
previous transmission from the financial institution or a 
duplicate reformatted file could be processed. If the 
transmission file is backed up, the reformat program could delete 
the transmission file after processing. If the reformat file is 
backed up, the ICAR system could delete it after processing. 

The ICAR system should be modified to reject identical payments 
being made with the same effective date and allow them to be 
processed as exceptions. 
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AUTOMATIC WITHDRAWAL FROM OBLIGOR CHECKING ACCOUNTS 



GENERAL INFORMATION 

Nature of" the System 

This EFT application is already available to obligors paying 
through Iowa's CSC. 

Environment 

Iowa and Nebraska are being used as case studies to assess the 
applicability of EFT technologies to child support. This 
document is sponsored by the Iowa-Nebraska Electronic Funds 
Transfer Project. 



OVERVIEW 

Purpose and Scope of the System 

Automatic withdrawal from obligor checking is already available 
to obligors paying through Iowa's CSC. Daily the CSC submits a 
computer tape through the bank to effect the transfer of funds 
from the relevant obligor's account to the CSC's account. 

The scope of this document is to define the necessary processes 
that would need to be implemented by the CSC in order to receive 
a payment request through an audio response unit (ARU). This 
document -will also address the necessary modifications required 
to ensure that an ACH payment will not be allowed until after the 
prenote period has elapsed. 

Performance Objectives 

Obligors: 

By initiating the automatic withdrawal through an ARU, the 
obligor will be able to manage his/her checking account more 
closely and determine the day the withdrawal is made. This 
eliminates the check writing process but allows the obligor a way 
to manage his/her checking account balance. 

CSC: 

A primary benefit of automatic withdrawal is the reduced manual 
effort in processing incoming paper checks. The most significant 
hurdle in implementing the automatic withdrawal program is 
gaining adequate voluntary participation among obligors. Many 
obligors are uncomfortable with automatic withdrawal since they 
cannot be sure their account will have enough funds to cover an 
automatic withdrawal every month on the same day. Participation 
should be greater with this system which allows the obligor to 
determine the day the withdrawal is made by calling an ARU. 
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Existing Methods and Procedures 



The automatic withdrawal from an obligor checking account has 
been offered by the CSC since May 1988. Currently, only a few 
individuals pay this way because this service is still in the 
initial implementation stages. The CSC submits a computer tape 
daily through the State's servicing financial institution to 
effect the transfer of funds from the obligor's account to the 
CSC's account. At the time that the tape is created, the ICAR 
system is automatically updated, eliminating the need to enter 
the receipt. The only entry required in these cases is for those 
rare instances when the automatic withdrawal cannot be completed 
due to insufficient funds. In these cases a manual correcting 
entry to the ICAR data base is required. 

Proposed Methods and Procedures 

Instead of the obligor signing up for a withdrawal that occurs on 
a specific schedule, he will call an audio response unit (ARU) 
and, through a tone generating telephone, update the ICAR system 
with the amount of payment and effective date that the payment 
should be made. All other methods and procedures will remain the 
same. 

This system could also be used by employers to have the CSC 
withdraw funds for income withholding payments. The process 
would be the same as for an individual obligor except that the 
account from which funds were withdrawn would be the employer's 
account and the access code would be issued to the employer only. 

Summary of Improvements 

The obligor benefits from eliminating the need to mail checks 
while maintaining the flexibility to manage his account balance. 
To the extent that these conveniences increase obligor 
participation in automatic withdrawal, the CSC benefits from the 
reduced effort in processing incoming paper checks. 

Summary of Impacts 

Hardware 

The ICAR system resides on an IBM-370 which uses OS/VS as 
the. operating system. Multiple personal computers operate 
in the CSC for support activity. 

An audio response unit (ARU) will need to be acquired. The 
ARU should be designed as a logical extension of the current 
system. It should be designed to replace an existing CRT 
and have the capability to interface with the ICAR 
application screens. The ARU will perform the function of a 
person who key-enters information to place an obligor on the 
automatic withdrawal program. This unit could be driven by 
existing 317X type controllers that are driving the CRT 
network. 
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Software 

The ICAR database is .developed in IDMS Cobol as the batch 
processing software with the on-line software written in 
ADSO. The following modifications to the ICAR Obligor EFT 
Authorization Screen ID# D479HR01 (see Appendix B) will be 
required to support this application: 

The field defined as "FREQUENCY" would need to 
support a type "0" for "On Request" payment. This 
would distinguish between automatic payments and 
payments requested through the ARU. 

Add a "CURRENT EFT AMT" field. This field would 
always be the same as the CASE EFT AMT unless 
requested through the ARU for a different payment 
amount. The "CURRENT EFT AMT field would be used 
during processing as the "CASE EFT AMT" field is 
currently being used. 

Add an "EFFECTIVE DATE" field. This field would 
always be set at 3 business days beyond the date the 
obligor called the ARU so the payment would be 
processed on the current day by ICAR. Each time an 
inquiry is performed on this screen, the "EFFECTIVE 
DATE" field would contain the current date plus 3 
business days. If the obligor wished to modify the 
"EFFECTIVE DATE", i.e., current date plus 5, it 
would become the new "START DATE". 

An "EFFECTIVE" field should be added next to the 
"PRENOTIFICATION" flag indicating the date that the 
prenotification will be complete. This date should 
be 10 calendar business days past the date the 
account was set up and the prenotification sent out 
through ACH. A calendar file may need to be created 
to determine this date. This calendar file should 
be accessed through a file maintenance screen. 

This field would be used by the staff who create the 
record to notify the obligor when he may begin to 
utilize the ARU or when the automatic withdrawal 
payments will begin. If a prenote is returned, this 
field should be reset for an additional 10-day 
period after the account information is corrected 
and another prenote is generated. 

The system should compare the "EFFECTIVE" field with 
the "EFFECTIVE DATE" field prior to initiating the 
automatic withdrawal transaction. Transactions 
should be initiated only if the "EFFECTIVE" field 
shows a date prior to that indicated by the 
"EFFECTIVE DATE" field. 
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An "ACCESS CODE" field which will contain the access 
code selected by the obligor and required to be 
input during the call to the ARU for identification 
purposes. 

When ICAR processes a record with a "FREQUENCY" of 
"0", it should blank out the "START DATE" field. 
The ARU will update the "START DATE" field with the 
new effective date (3 business days from current 
date) when a call is completed. 

The Obligor EFT Authorization Screen ID#D479HR01 
will need to be accessed by "INITIAL CASE NUMBER" 

Operational 

Since this system will process ARU initiated payments the 
same as Automatic Withdrawal payments, the system should not 
create a negative impact on staff workloads. 

Organizational 

This system should be managed by the CSC with staff that 
currently operates the automatic withdrawal process. 



REQUIREMENTS 
Functions 

This system will be required to perform the following functions: 

Allow an obligor to call an ARU and authorize the CSC to 
originate an ACH entry for a payment; 

Processing of ARU originating payments will be the same as 
automatic withdrawal payments. 

The ARU would function as a CRT operator accessing the Obligor 
EFT Authorization screen ID# D479HR01. The following represents 
a sample script and the correspondent functions for the ARU: 

"Welcome to the Iowa Automated Collection System." 

Z 1 , eas ?-, enter your case numb er." After receiving input, the 
ARU will then perform a PF5 using the case number on the 
Obligor EFT Authorization Screen to determine a valid case 
number. 

"Please enter your Access Code." The ARU will then compare 
the Access Code entered with the ACCESS CODE field on the 
screen and continue if a match is found, otherwise, the ARU 
will speak "invalid ACCESS CODE please reenter". If the 
obligor makes several incorrect attempts, the ARU will 
terminate the call. 
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"The amount of your payment is '$400.00' (from the CASE EFT 
AMT field). Is this correct? Press 1 for yes or 9 for 
no." 

If Yes, the ARU will place the "CASE EFT AMT" into 
the "CURRENT EFT AMOUNT" field and move to the next 
prompt. 

If No, the ARU will speak "Please enter the amount 
you would like to pay. Enter the dollar and cents 
separately. Enter the dollars you would like to pay 
and press the pound sign. Enter the cents you would 
like to pay and press the pound sign. You have 
entered '$350.00'. Is this correct? Press 1 for 
yes or 9 for no." After a yes answer, the ARU will 
place this amount into the "CURRENT EFT AMOUNT" 
field which will be picked up by ICAR as the new 
payment amount. 

"The effective date of your payment is 'September 19, 1988' 
(from the EFFECTIVE DATE field). Is- this correct? Press 1 
for yes or 9 for no." 

If Yes, the "EFFECTIVE DATE" will be used to update 
the "START DATE" field and the ARU will move to the 
next prompt. 

If No, the ARU will speak "Please enter a subsequent 
two digit month and two digit day on which you would 
like your payment to be effective and press the 
pound sign. You have entered 'September 27, 1988'. 
. Press 1 for yes or 9 for no." If no, the ARU will 
provide another chance to change date. 

"You have requested a payment of '$350.00' on 'September 27, 
1988'. Press 1 for yes or 9 for no." 

If yes, the ARU will speak "Thank you for making 
your payment through the Iowa Automated Collection 
System." 

If no, the ARU will return to the prompt after 
"ACCESS CODE" verification. 

Performance 
Accuracy 

The "ACCESS CODE" field should not be allowed to be given to 
the obligor or any other party over the telephone. It will 
be important to inform obligors of the importance of 
maintaining the confidentially of this code. 
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Flexibil i ty 

The ARU may also be configured to provide obligors a method 
"of inquiring on previous payment amounts if so desired. 

Inputs and Outputs 

Inputs 

Input into the system will be through the ARU which will act 
as a CRT operator. The payment and date fields will be 
updated by the ARU and the file will be processed by ICAR 
like the current automatic withdrawal system. 

Output 

Output from the system would be the same output as currently 
provided by the automatic withdrawal system. 

Failure Contingencies 

Backup 

The software on the ARU should be backed up for contingency 
planning should the unit fail and a new unit be required. 

Fall Back 

If for any reason the ARU is unavailable, customer service 
can provide the same service by accessing the same CRT 
screen. 

Recovery and Restart 

The system should be designed to automatically logon and 
supply the ARU with the Obligor EFT Authorization Screen. 
This will allow the ARU to begin processing. 

Documentation 

The following documentation should be produced and become an 
inherent part of this system: 

An Operations Manual containing instructions on operating 
.the hardware and modifying the software of the ARU; 

The General and Detail Design documents which are produced 
to develop this system. 

OPERATING ENVIRONMENT 

Equipment 

I8M-370 Mainframe 
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Audio Response Unit (ARU) which attaches to a controller which is 
currently driving the CSC CRT's 

Support Software 

ARU- development software, which typically comes with the ARU, is 
required for development of the system. 



Interfaces 

The ARU will interface with the IBM-370 as a 327X terminal. It 
will communicate with the IBM-370 through an existing 327X 
controller. 

Controls 

No specific controls are necessary for this system. 
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DIRECT DEPOSIT TO OBLIGEE CHECKING ACCOUNTS 



GENERAL INFORMATION 

Nature of the System 

This EFT application is already available to obligees receiving 
payments through Iowa's Collection Services Center (CSC). 

Environment - Identify the project Sponsor 

Iowa and Nebraska are being used as case studies to assess the 
applicability of EFT technologies to child support. This 
document is sponsored by the Iowa-Nebraska Electronic Funds 
Transfer Project. 



Purpose and Scope of the System 

Iowa's CSC currently creates daily ACH tapes that effect direct 
deposit of funds to obligee checking accounts. This provides 
obligees with the convenience of not needing to deliver or mail 
their child support payment to the bank for deposit. 

The scope of this document is to define the functional 
specifications for an ARU to receive obligee inquiries about 
deposits, to define modifications that may be necessary to ensure 
a 10-day delay after pre-notification before direct deposits are 
initiated, and to define modifications that allow concurrent 
automatic withdrawal and direct deposit. 

Performance Objectives 



Obligee inquiries can be handled more effectively if routine 
payment questions are answered by an audio response unit 
(ARU). This allows customer service personnel to spend more 
time responding to non-routine inquiries. 

Concurrent automatic withdrawal and direct deposit will 
reduce the number of days required to deliver payment 
payment to the obligee. 



OVERVIEW 



Obi igees: 



CSC: 



By providing a convenient 
CSC may be able to reduce 
notifications it sends to 
administrative expense. 



inquiry method for obligees, the 
the number of deposit 
obligees and thus save 



- 21 



By safeguarding against originating ACH entries earlier that 10 
days after the pre-note is generated, the CSC ensures conformity 
to ACH regulations and avoids generating incorrect ACH 
transactions. 

Concurrent automatic withdrawal and direct deposit allow the CSC 
to achieve its aim of delivering payments to obligees as quickly 
as possible. 

Existing Methods and Procedures 

Direct deposit to obligee checking accounts has been offered by 
the CSC since May 1988. Currently, only a few individuals 
receive payments this way because this service is still in the 
initial implementation stages. 

After funds are received from the obligor, the CSC submits a tape 
of these direct deposits daily to the State servicing bank. The 
bank submits the transactions to the ACH to effect the transfer 
of funds from the CSC's account to the obligee's account. The 
deposit to the obligee's account is completed the day after the 
tape is submitted to the bank by the CSC. 

Currently, a deposit notice is sent to the obligee informing 
him/her of the receipt. However, Regulation E of the Federal 
Reserve Board does not require an entity making a deposit into a 
consumer account to provide a notice of deposit in cases where 
the deposit amount remains the same from period to period. The 
receiving financial institution has the responsibility of 
notifying its customer of deposits made. Notification of deposit 
is usually given to the customer by both the periodic bank 
statement and a customer service operator who confirms deposit 
amounts. 

Proposed Methods and Procedures 

Obligees will have the opportunity to use any tone-generating 
telephone to access an audio response unit (ARU) to determine 
when the last payment was made for their case. This function 
would be available to all obligees. 

With the ARU system available, the CSC may choose not to mail a 
deposit notice to obligees on direct deposit. This document 
assumes that deposit notification is not desired. The CSC may 
elect to give obligees the option of receiving deposit 
notification. Other system changes not acdressed in this 
document would be required to accommodate that functionality. 

When an direct deposit authorization is entered on the Obligee 
EFT Authorization screen, a new field will be used to record the 
end date of the 10-day wait period after the pre-note is 
initiated. When actual payments are initiated, this field 
(EFFECTIVE DATE) will be checked to see that the prenote delay 
period has expired. 
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The delay in receipting automatic withdrawals, will be reduced to 
one day so that automatic withdrawals and direct deposits may be 
effective concurrently. 

Summary of Improvements 

Three improvements will be accomplished when this system has been 
implemented. First, an obligee could call into the system from 
any tone-generating telephone, identify himself/herself by case 
number and obtain information about payment status. This would 
eliminate the need for the CSC to mail out a deposit notice and 
provide more efficient customer service. Second, the State will 
meet the guidelines set up by ACH by allowing deposits to only 
occur after the 10 day delay after pre-notification. Third, 
concurrent withdrawal/deposit will allow the obligees to receive 
payments in a more timely fashion. 

Summary of Impacts 

Hardware 

The ICAR system resides on an IBM-370 which uses OS/VS as 
the operating system. Multiple personal computers operate 
in the CSC for support activity. 

The same ARU identified in the Automatic Withdrawal document 
will be utilized for this application. 

Software 

The ICAR database is developed in IDMS Cobol as the batch 
processing software with the on-line software written in 
ADSO. The following modifications will be required to 
support this application: 

ICAR Obligee EFT Authorization Screen ID# D479HR13 (see 
Appendix C) should be modified to support the 
following: 

An "EFFECTIVE" field should be added next to the 
"PRENOTIFICATION" flag indicating the date that 
the prenotification will be complete. This date 
should be 10 calendar days past the date the 
account was setup and the prenote was initiated. 
A calendar file may need to be created to 
determine this date. This calendar file should be 
accessed through a file maintenance screen. 

The ICAR system should compare the "EFFECTIVE" 
field with the date on which direct deposits are 
initiated. Transactions should be intiated only 
if the "EFFECTIVE" field shows a date prior to the 
current date (date of transmission). 
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This field would also be used by the CSC staff to 
notify the obligor when he/she may begin to 
utilize the ARU or when the automatic withdrawal 
payments will begin. 

The Payment Look Up Screen ID#D479HS16 (see 
Appendix D) will need to be accessible by "INITIAL 
CASE NUMBER" (Screen Name "Account Number"). This 
may require system changes if this function is not 
currently available. 

The two day delay in receipting automatic 
withdrawals should be reduced to one day. This 
would actually record the receipt before the funds 
were available to the CSC, but would make the 
direct deposit effective on the same day as the 
automatic withdrawal . 

The deposit notification generation capabilities 
of the payment system should be defeated so that 
no deposit notifications are mailed to obligees. 

Operational 

No negative operational impacts should occur from this 
system. 

Organizational 

This system should be managed by the CSC with staff that 
currently operates the automatic withdrawal process. 



REQUIREMENTS 
Functions 

This system will be required to perform the following functions: 

Allow an obligee to call the ARU and inquire about the date 
of the last payment. 

Provide a check of the "EFFECTIVE" date field prior to 
initiation of a direct deposit so that no payments are made 
before the 10-day prenotification delay expires. 

Allow concurrent automatic withdrawals and direct deposits. 
Once the delay in receipting automatic withdrawals is 
reduced to one day, the withdrawal and deposit transactions 
should be effective on the same day. 
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The ARU would function as a CRT operator accessing the Payment 
Look Up Screen I0# D479HS16 (see Appendx 0). The following 
represents a sample script for the ARU: 



"Welcome to the Iowa Automated Collection System, " 

"To make a payment, press 1." 

(See the automatic withdrawal section for the script 
for making a payment.) 

"To inquire about a payment, press 2." 

"Please enter your case number." The ARU will then perform 
a PF5 using the case number on the Payment Look Up Screen 
ID# D479HS16 to determine a valid case number. 

"Payment amounts and the dates received are as follows: 
'September 1', '$400.00'; 'August 1' , '$400.00'. The ARU 
will give then speak 'Receipt Date' and 'Receipt Amount' for 
as many dates as the CSC desires. 

"To make additional inquiries', press 3, otherwise hang up." 
The ARU will then pass the call to a human operator if the 
"3" is pressed otherwise, it will terminate the call. 

Performance 
Accuracy 

Payment information should not require a password since the 
telephone inquirer needs to know the case number and dates 
and amounts are not sensitive information. 

Flexibil ity 

The ARU should be developed in conjunction with the 
automatic withdrawal system. 

Inputs and Outputs 

Inputs 

Input into the system will be through the ARU which will act 
as a CRT operator. 

Output 

Implementation of this system does not create any additional 
output. It does eliminate the need for the deposit advice 
currently being mailed to obligee. 
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Failure Contingencies 
Backup 

The software on the ARU should be backed up for contingency 
planning should the unit fail and a new unit be required. 

Fall Back 

If for any reason the ARU is unavailable, customer service 
can provide the same service by accessing the same CRT 
screen. 

Recovery and Restart 

The system should be designed to automatically logon and 
supply the ARU with the Payment look up screen. This will 
allow the ARU to begin processing. 

Documentation 

The following documentation should be produced and become an 
inherent part of this system: 

Operations Manual containing instructions on operating the 
hardware and modifying the software of the ARU. 

General and Detail Design documents which are produced to 
develop this system. 



OPERATING ENVIRONMENT 
Equipment 

IBM-370 Mainframe 

Audio Response Unit (ARU) which attaches to a controller which is 
currently driving the CSC CRT's. 

Support Software 

ARU development software which typically comes with the ARU. 



Interfaces 

The ARU will interface with the IBM-370 as a 327X terminal. It 
will communicate with the IBM-370 through an existing 327X 
controller. 

Controls 

No specific controls are necessary for this system. 
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CHARGES TO OBLIGOR CREDIT CARD ACCOUNTS 



GENERAL INFORMATION 

Nature of the System 

Accepting credit card payments from obligors has the primary 
advantage of offering obligors an alternate means of remittance 
that may increase the likelihood of consistent payment. Agencies 
can be given authorization by obligors to automatically charge 
their credit card accounts at specified times in specified 
amounts. For prearranged periodic charges, the State would 
periodically submit to the processor or bank an electronic file 
of accounts for credit card charges. These items are also 
processed on a daily basis therefore meeting the need for 
immediate settlement and availability of funds. 



OVERVIEW 

Background, Purpose and Scope of the System: 

Currently, the only forms of payment accepted by the CSC are 
checks, money orders, automatic withdrawals from checking or 
savings, cash or cashier's checks. Credit cards could be an 
alternate form of payment accepted in two ways: 

As a prearranged periodic charge to the obligor's credit 
card (which would not require the physical card to be 
present) , 

As an obligor-initiated charge recorded by an audio response 
unit (ARU). 

The scope of this document is to define the necessary processes 
and materials needed to implement credit card acceptance, 
remittance and settlement via electronic means in order to 
expedite obligor payments. 

This document assumes that the MasterCard and Visa bankcards are 
the only cards accepted for payment. The term "credit card" is 
used throughout this document to reference these two bankcards. 

This document assumes a PC-based system for initiating credit 
card charges rather than a mainframe system. This is done to 
minimize the development time necessary to put the payment 
process in place by eliminating the need to specify a mainframe 
application to format, generate and transmit credit card 
transaction files. The PC-based system also offers the 
flexibility of submitting small numbers of daily credit card 
transactions. This is not possible with a mainframe application. 
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Performance Objectives 
Obi igor: 

Credit card acceptance offers the obligor an alternative 
payment method that may be more convenient and easier to 
manage than cash or check payment. Prearranged charges 
offer the obligor the convenience of automatic payment as 
well as protection against forgetting to make the payment. 
Credit card payment initiated through an ARU allows the 
obligor the additional convenience of being able to 
determine the effective date of the charge. 

CSC: 

Accepting credit cards may secure payment from obligors who 
would not otherwise pay consistently and help the Clerk's 
office provide payments for more obligees. The prearranged 
credit card process would reduce the administrative work 
for the CSC of processing and depositing checks. 

Existing Methods and Procedures 

Since the CSC currently does not employ the acceptance of credit 
cards for child support payments, existing methods or procedures 
do not apply. 

Proposed Methods and Procedures 

Prearranged periodic credit card charges would work as follows: 

The CSC would obtain a form from the obligor authorizing it 
to charge his/her account each month for the payment 
amount. Each day the CSC would present to its processor or 
financial institution a file of those accounts to be 
charged. As with the automatic withdrawal process, some 
administrative effort will be involved initially in handling 
applications and authorization forms. The daily process of 
producing files to initiate the charges will require a small 
amount of time. 

Credit card charges initiated by an obligor accessing an ARU 
would work as follows: 

The process for handling ARU-initiated transactions would be 
very similar to that for handling monthly prearranged 
charges. However, the charge would not be initiated until 
the obligor accessed the ARU through a tone-generating 
telephone, input his/her case number and access code and 
answered several questions, authorizing the county to charge 
the payment to the credit card. The charge would then be 
merged with the prearranged credit card charges and 
transmitted to the processor or financial institution for 
settlement. 
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Transmission of prearranged periodic charges for batch processing 
is somewhat involved and most processors require a minimum number 
of transactions (200) per deposit. Variables such as speed of 
data transmission and format of transaction information should be 
researched during processor selection. Batch processing is quite 
economical with higher transaction volumes. 

Due to the minimum daily transaction volumes and higher initial 
expense involved with batch processing, it may be practical to 
initially process all credit card transactions individually. 
This can be accomplished by using a point-of-sale (POS) terminal 
or PC software that emulates a POS terminal. The operator would 
simply enter the credit card number, enter the dollar amount of 
the payment being collected and send the transaction to the 
processor for authorization and capture. 

Prearranged periodic charges could be maintained by a "tickler" 
file system that grouped obligor credit card information by the 
date that payment is to be initiated. Each day, the appropriate 
file could be printed so that the charges could be entered into 
the POS terminal (or POS emulation program on the PC). The 
ARU-initiated charges for that day could be handled in the same 
manner. 

Summary of Improvements 

Accepting credit card payments offers the obligor an alternative 
payment method which may increase the likelihood of consistent 
payment. Prearranged periodic charges make the funds available 
soon after the court-ordered due date. Electronic transaction 
processing reduces the time required to prepare deposits. 

Summary of Impacts 

Hardware 

An ARU will need to be acquired. The ARU should be designed 
to operate on an IBM compatible personal computer so that 
the credit card software could also be resident and utilized 
for processing. 

The PC must support a 300 baud modem and a printer. 

A standard dot matrix printer will be required for reporting 
of ARU activity. 

A 300 baud modem will be required for transmitting the 
credit card batch file (if used) to the processor or 
financial institution. 

A POS terminal with printer will be required if this method 
of submitting credit card payments is used. 
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Software 

A data base will be required on the PC supporting the ARU. 
This date base will require the following elements: 

Case Number 

Case Name 

Access Code 

Payment Amount 

Credit Card Number 

Credit Card Expiration Date 

Pre-authorization Date 

Case Type (Indicator for Child Support vs. Alimony) 

A PC-based software package from the selected processor or 
financial institution will be required to initiate the 
credit card charges if a POS terminal is not used. This may 
be either batch processing software, if transaction volumes 
are sufficient, or it may be POS emulation software. 

A customized ARU application will need to be developed. 

A Oaily Transaction Report will need to be created on the PC 
to document daily activity. This report should contain the 
following information: 

Transaction Date 
Transaction Time 
Case Number 
Case Name 

Credit Card Number 

Credit Card Expiration Date 

Payment Amount 

Total Number of Payments 

Total Dollars of Payments 

A PC-based report and/or file generation program will need 
to be developed to generate input for the ICAR to record 
credit card receipts. 

Operational 

Since this is in additional payment method not currently 
utilized by the CSC, processing will require some additional 
operations time. This will be offset to some extent by the 
reduction in number of checks processed. 

Organizational 

This system should be managed by the CSC with staff that 
currently operates and reconciles the remittance processing 
and receipting functions. 
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REQUIREMENTS , 
Functions 

Prearranged periodic credit card charges would work as follows: 

The CSC would first obtain a form from the obligor 
authorizing it to charge his/her account each month (or more 
frequent period) for the payment amount. Initially, the 
daily transaction volume may be too low to make batch 
processing practical. Charges to be initiated for a given 
day of the month would be recorded in a common file on the 
PC. On the appropriate date, these records would be printed 
for the operator to manually enter into a POS terminal or 
transfer to a POS emulation program on the PC. Charges 
received that day through the ARU would also be printed for 
entry in the same manner. 

Using the POS terminal or POS emulation program, the 
operator would simply enter the credit card number and 
dollar amount of the payment being collected and transmit 
the transaction to the processor for authorization. Each 
transaction would be submitted individually and receive a 
separate authorization. 

At the end of the day (or the end of the session), the 
operator would initiate the settlement and deposit process. 
The operator would total the number of transactions and the 
dollar amount of those transactions from the reports. The 
operator would then compare these totals with those recorded 
by the POS terminal and the processor. When all totals 
agree, a settlement transaction would be initiated to 
confirm the deposit amount. 

As transaction volume grows, a PC-based batch processing 
system could be used. Then, each day the CSC would present 
to its processor or financial institution a file of those 
accounts to be charged. This would be accomplished 
utilizing a software package provided by the selected 
processor or financial institution. This file would also 
contain the transactions that were initiated through the 
ARU. 

The funds for all credit card charges will be deposited into 
the CSC's account within one to three days and will be 
reflected on the daily account statement. Detailed reports 
will be provided from the software package to document the 
charges and confirm the total deposit amount. 

The obligor initiated payment system would perform the following 
functions: 

Allow an obligor to call an ARU through a tone generating 
telephone and authorize the State to originate a charge to a 
pre- authorized credit card. 
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Process ARU originated payments in the same as 
pre-authorized monthly payments. 

The ARU would function as an operator obtaining required 
information necessary for the acceptance of a payment. The 
following represents a typical script for the ARU: 

"Welcome to the Iowa Automated Collection System." 

"Please enter your case number. " The ARU will then access 
the data base that resides on the PC to determine if the 
case number has been pre-authorized. 

"Please enter your access code." The ARU will then compare 
the access code entered with the ACCESS CODE field on the 
data base screen and continue if a match is found, 
otherwise, the ARU will speak "invalid ACCESS CODE, please 
reenter". If the obligor makes several incorrect attempts, 
the ARU will terminate the call. 

"The amount of your payment is '$400.00' (from the 
pre-authorized amount in the data base). Is this correct? 
Press 1 for yes or 9 for no." 

If Yes, the ARU will move to the next prompt. 

If No, the ARU will speak "please enter the amount you 
would like to pay. Enter the dollar and cents 
separately. Enter the dollars you would like to pay 
and press the pound sign. Enter the cents you would 
like to pay and press the pound sign. You have entered 
'$350.00' . Is this correct? Press 1 for yes or 9 for 
no". 

"You have requested a payment of '$400.00' applied to your 
pre-authorized credit card. Press 1 for yes or 9 for no." 

If yes, the ARU will speak "thank you for making your 
payment through the Iowa Automated Collection System". 

If no, the ARU will return to the prompt after "ACCESS 
CODE" verification. 

A Daily Transaction Report should be run to provide detail 
information pertaining to each day's activity. This report 
will contain sufficient information to manually process the 
payments with the POS terminal, if desired. Otherwise, 
these payments would then be merged into the batch file that 
is transmitted daily to the processor or financial 
institution. 
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Several options exist for entering the receipt information into 
the ICAR system: 

"CSC staff could perform "a manual receipting procedure for 
each credit card charge as is now done for the cash or check 
- payments which are received without coupons. A PC-generated 
daily report can be used to enter the receipts. 

A report program could be developed which would allow the PC 
to print a payment coupon for each credit card charge 
initiated. This could be a part of a batch processing 
system or the POS-based entry system. The coupon would then 
be processed through the remittance processing system. 

Finally, the credit card charges could be formatted into a 
file format similar to the remittance processing system file 
that is transmitted to the IBM-370 each day. This file 
would need to include some data elements, such as case 
number, from the PC data base which are not on the credit 
card transaction itself. The ICAR system would need to be 
modified to merge these records into the remittance 
processing file for input. 

Performance 

Accuracy 

As the data base is created, it is important to ensure that 
the credit card numbers being input are accurate. A 
"pre-auth" transaction for $1.00 should be performed for 
each credit card as it is being set up on the data base. 
This can be done by using the POS terminal or the POS 
emulation program on the PC if either of these are 
available. A voice authorization could be obtained if a 
batch processing system were being used. 

This transaction will ensure that each card is valid and the 
information provided is correct. A "pre-auth" transaction 
will not affect settlement totals, will not actually 
transfer any funds and will not be reported on the obligor's 
credit card account statement. 

Flexibility 

The system should be designed to support additional case 

types such as alimony for future expansion of this 

collection system. 

Inputs and Outputs 

Inputs 

Authorization forms and POS terminal receipts must be kept 
on file according to the requirements of the processor or 
financial institution. 
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•. When a batch transmission file is sent to the processor or 
financial institution for pre-authorized or ARU-ini tiated 
.credit card payments, rejected charges will automatically be 
returned to the PC. The CSC will have to reverse the 
receipting process when this occurs. 

Outputs 

The ARU will produce a file for input into the software 
program provided by the processor or financial institution 
for obligor-initiated credit card payments. 

The following reports will need to be generated on the PC 
for settlement and reconcilement: 

Daily Transaction Report reflecting ARU activity, 

Daily Activity Report provided by the processor's 
software program to report the charges that were 
accepted and deposited. 

Input into the receipting system would remain the same as is 
currently being performed for cash or checks. 



FAILURE CONTINGENCIES 
Backup 

The software on the ARU should be backed up as a contingency if 
failure of the ARU occurs and a replacement is required. 

The PC program should contain an automatic backup for protection 
of the data base. This could be done on diskette until such a 
time that the data base grows and a tape backup unit would be 
practical . 

Fall Back 

If for any reason the ARU and PC fail, the State has sufficient 
information on hand to manually create a paper draft which can be 
deposited at the financial institution. This procedure, although 
cumbersome, will allow payments to continue to be made. 

Recovery and Restart 

The batch processing system should not allow the same credit card 
payments to be transmitted on consecutive days. The system 
should allow for credits to be processed should an error occur 
and an improper credit card charge be processed. 

Documentation 

The following documentation should be provided and become an 
inherent part of this system: 

Operations manual for ARU system, PC system. 
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Operations manual for the batch processing software program 
provided by the selected processor or financial institution. 

User's Manual containing information on a detail level of 
all reporting, reconciliation procedures, and exception 
* processing. 

General and Detail Design documents which are produced to 
develop this system. 



OPERATING ENVIRONMENT 
Equipment 

Audio response unit operating on an IBM or compatible personal 
computer 

Dot Matrix printer for personal computer 

300 baud modem for personal computer 

Support Software 

Software provided by processor or financial institution which 
provides functionality for batch processing of credit card 
payments. 

Software provided by ARU manufacturer which provides initial 
functional ity. 

Interfaces 

Single interface to financial institution or processor which is 
provided by software package. 

Controls 

The system should be designed to limit the possibility that a 
previous transmission to the processor or financial institution 
• could be duplicated. 
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III. 

PILOT PROJECT WORKPLAN 



The following represents a suggested workplan for the implementation of 
the Iowa EFT pilot project. This workplan is divided into 6 components 
with an estimated project month duration identified for each component. 
Each component is described below. 

Project Initiation - (PI) - This phase is utilized for procurement of 
the project implementation management vendor and for market research, 
final project definition and contract execution. 

Phase 1 (DESIGN) - (PI) - This phase of the project is utilized for 
definition of requirements and identification of delivery dates, 
relevant options and issues to be considered for the successful 
implementation of this project. 

Phase 2 (DEVELOPMENT) - (P2) - Upon completion of the Design phase, 
the Development phase begins. This phase consists of the following 
elements: 

Conversion Requirements 

System Programming Requirements and Software Modification 

Unit Test Requirements and Testing 

System Testing Requirements and Testing 

Documentation Requirements and Creation 

User Training Procedures and Plan 

Installation Checklist Documentation 

Phase 3 (IMPLEMENTATION) - (P3) - This phase is utilized for the final 
completion of all documentation, training of users, and preparation of 
physical environment. 

Phase 4 (OPERATION) - (P4) - This phase includes initial operation of 
the pilot system, development of evaluation criteria and evaluation of 
the system. 

Project Evaluation - (PE) - This phase allows for the creation of the 
final project evaluation report to the State and for on-going 
maintenance of the system. 

Included with this workplan is a detail list of activities and 
deliverables. Each task description is identified with the two digit 
acronym which is defined above for each component, i.e., PI, PI. P2 etc. 
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ACTIVITIES AND DELIVERABLES 



Task Task 

|_ Description 

1. PI - Select Vendor for Implementation Management 

Project Implementation. 

2. PI - Perform Market Survey 

Employers 
Obligors/Obligees 

3. PI - Execute Contract 

4. PI - Vendor/Iowa Planning Meeting 

5. PI - Evaluate Market Survey Results 

6. PI - Vendor Completes Systems Specifications 

7- PI - Iowa Receives/Reviews Systems Specifications 

8- PI - Meeting to Finalize Systems Specifications 

9- PI - Vendor Submits Final Systems Specifications Document 

10. PI - Iowa Receives Status Report 

11. PI - Iowa Approves Final System Specifications Document 

12. P2 - Complete System Design Document 

13. P2 - Select Vendor for Hardware and Software 

14. P2 - Oevel op/Modify ICAR System 

15. P2 - Develop/Modify Reports 

16. P2 - Develop/Modify Administrative Terminal System (ICAR) 

17. P2 - Receive Hardware Defined in Specifications 

18. P2 - Develop/Modify ARU System Software 

19. P2 - Draft Financial Institution Settlement Guide 

20. P2 - Draft Client Application 
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Task Task 

£_ Description 



21. 


P2 


- 


System Unit Testing Begins 


22. 


P2 


- 


Iowa Receives Status Report 


23. 


P2 


- 


Formalize Employer Participation 


24. 


P2 


- 


Finalize Financial Institution Settlement Guide 


25. 


P2 


- 


Finalize Client Application 


26. 


P2 


- 


Draft Administrative Terminal Training Guide 


27. 


P2 


- 


Draft Iowa Report Manual 


28. 


P2 


- 


Draft Iowa User Manual 


29. 


P3 


- 


Mail Iowa Client Application 


30. 


P3 


- 


Finalize Administrative Terminal Training Guide 


31. 


P3 


- 


Finalize Iowa Report Manual 


32. 


P3 


- 


Finalize Iowa User Manual 


33. 


P3 


- 


Open Financial Institution Clearing Account (If Necessary) 


34. 


P3 


- 


Evaluate Staff Requirements 


35. 


P3 


- 


Verify Financial Institution Clearing Account Is Open 


36. 


P3 


- 


Hire Staff as Required 


37. 


P3 


- 


Complete Training Documentation and Materials 


38. 


P3 


- 


Verify Billing Process for Iowa 


39. 


P3 


- 


Iowa Approves Training Material 


40. 


P3 


- 


Hire Voice for ARU 


41. 


P3 




Train Trainers 


42. 


P3 




Perform Financial Institution Settlement Training 


43. 


P3 




Complete Iowa Settlement Training 


44. 


P3 




Translate ARU Vocabulary to Additional Language if Required 


45. 


P3 




Perform Iowa User Training 
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Task 

j 




Task 
OescriDtion 


46. 


P3 


- Complete System Unit Test 


47. 


P3 


- Order Equipment 


48. 


P3 


- Order Communication Lines 


49. 


P3 


- Vendor Performs Integrated System Test 


50. 


P3 


- Iowa/Vendor Performs User Certification Test 


51. 


P3 


- Install Communication Lines 


52. 


P3 


- Install Equipment 


53. 


P4 


- Iowa Receives Status Report 


54. 


P4 


- Vendor Assists with Project Evaluation Criteria 


55. 


P4 


- Process Client Applications 


55. 


P4 


- System Goes Live 


57. 


P4 


- Vendor/Iowa Monitors Reports Daily 


58. 


P4 


- Vendor Profides Continual Customer Support 


59. 




- Vendor/Iowa Monitor & Evaluate System Performance 


60. 




- Vendor Participates in Final Evaluation 


61. 




- Provide On-Going Maintenance 
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SECTION IV. 
COST BENEFIT SUMMARY 



This section summarizes the major costs and benefits of each of the selected 
EFT applications for child support collection and distribution. As there are 
yet several choices to be made in the implementation of this project, all the 
costs and .benefits cannot be fully estimated. Of .particular note are the costs 
for modifications to the ICAR system. Internal cost estimates can -be generated 
as system elements are more fully defined. 

Some cost elements depend on the specific hardware and software items 
selected. These costs can be determined as proposals are solicited from 
vendors. 

Finally, there will be additional costs associated with implementation 
management and installation assistance. These will include costs for both 
State staff and the implementation management vendor. 

Given the options and uncertainties, no attempt was made to compute a total 
cost for the project or a formal cost/benefit ratio. This will become more 
clear during the early phases of the pilot project and will be a part of the 
formal pilot project evaluation. 



DIRECT DEPOSIT OF EMPLOYER INCOME WITHHOLDING 

For employers involved in income withholding, there are several advantages of 
doing so by direct deposit: 

Direct deposit eliminates the time and expense of preparing and sending 
checks to the CSC for each payroll period. For those employers who send a 
check for each employee, the cost savings could be substantial. 

Similarly, direct deposit eliminates the time and expense of preparing and 
sending to the CSC a listing of employees for whom the payment should be 
applied.. The savings would vary by employer according to the number of 
employees with income withholding and the current administrative procedures 
used by the employer. 

Once an employee's child support payment is set up on the payroll system, 
the employer need take no further action unless the child support amount is 
changed. 

The CSC and obligees benefit from the direct deposit of income withholding in 
the following ways: 

The payments would be credited to the CSC's account precisely on the 
payroll date, avoiding the current five days or so that elapse while the 
employer's payroll personnel prepare the list of employees, write the 
check, and send the payment through the mail to the CSC. 

The funds would be automatically deposited into the CSC's account, saving 
the staff time required to physically deposit these items. 
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The payments could be automatically recorded in the ICAR system and 
reduce the staff time required to manually enter the payments. 

The costs for" employers are minimal " They would be charged a fee by their 
bank of approximately $ .06 to $.08 per direct deposit. For those 
employers who send a check for each employee, they would save the cost of 
generating each check. If the employer made a separate transmission to 
their bank (apart from the payroll direct deposit transmission), they 
would be charged a fee of approximately $10-525 per transmission. These 
costs would likely be outweighed by the convenience and time savings from 
reduced administrative work in handling the payments through ACH. 

For the CSC, the costs would be $.20 per payment received. The financial 
institution charges $.20 per deposit credit, regardless of size or the 
number of items included in the deposit. Unlike deposits of checks, which 
may have many payments recorded on a single deposit, each direct deposit 
payment results in a separate credit recorded in the account. 

This deposit cost will not be a significant initially, since the number of 
transactions will be small. However, as volume grows, this cost will 
become substantial. The potential may exist for the financial institution 
to price electronic deposits separately from other deposits to 
appropriately reflect the lower cost of receiving electronic items. 

As described in the system specifications, several options exist for 
receiving payment information from the financial institution and 
formatting it for input in to the ICAR system. The hardware and software 
required for receipt of payment information by tape transfer are 
understood to be available. If an existing bank relationship is used, no 
incremental costs for tape transfer would be incurred. Otherwise, a tape 
or transmission fee of approximately $100 per month would likely be 
incurred. Receipt of payment information by transmission would also 
require modem capabilities of either the mainframe computer or a PC. 

If the payments are manually entered into the ICAR system, as income 
withholding payments are currently, no cost impact will result. However, 
automated update of the ICAR system would require an investment in 
programming to yield administrative time savings. Internal cost estimates 
for programming need to be prepared for the selected input option. 

AUTOMATIC WITHDRAWAL FROM OGLIBOR CHECKING ACCOUNTS 

The CSC currently offers obligors the convenience of automatic 
withdrawal. Obligors save the time and expense of writing checks while 
eliminating the possibility of forgetting to make a payment. 
Obligor-initiated withdrawal made by accessing an ARU would provide the 
obligor with the additional convenience of being able to time the payment 
to better manage his checking account balance. Obligees benefit by 
receiving payment earlier and more regularly. Withdrawals are submitted 
so that the funds are available to the CSC precisely on the due date 
specified by the court order. This avoids the mail delays that occur when 
obligors mail their payments on the date due or soon after. 
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For the CSC, the administrative work of processing and depositing these 
payments is eliminated. The automatic withdrawal process automatically 
updates the ICAR system for the receipts initiated. 

No costs are incurred by either the obligor or obligee for this process. 

The CSC incurs the following costs for operating the automatic withdrawal 
process: 

Tape charges A maximum of $150 per month 

Transaction fees $.06 per transaction (approximate) 

Additional costs are incurred for printing and mailing the applications 
and for staff time for setting up and maintaining the records on the 
system. 

The costs to the CSC for obligor-initiated withdrawals utilizing an ARU 
would be as follows: 

ARU hardware, software, $28,000 (approximate) 

and installation 

Monthly licensing and $300 per month (approximate) 

maintenance for hardware 
and software 

Telephone lines $100 each for installation 

$ 50 per month 

ARU programming and $16,000 (approximate) 

voice recording 

Actual costs and system configuration will depend on the ARU system chosen 
and the volume of calls received. ARU programming costs, based on a rough 
estimate of 40 person-days of work, will vary with the ARU system chosen 
and the complexity of the interface with the ICAR system. The amounts 
noted for telephone lines are customary rates. The CSC may be able to 
obtain more favorable pricing. Internal costs will also be incurred for 
the ICAR system modifications described in the system specifications. 

DIRECT DEPOSIT TO OBLIGEE CHECKING ACCOUNTS 

The CSC currently offers obligees the convenience of direct deposit. The 
obligees no longer need to wait for the check to come in the mail and then 
take the check to the bank to deposit it. Additionally, their funds are 
available within one day after payment is initiated by the CSC. This time 
compares favorably to the approximately four days it takes for mail 
delivery and deposit of checks. 
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The direct deposit approach offers potential savings to the CSC of 
approximately $.2674 per transaction by avoiding the following costs for 
warrant production: 



Warrant stock 

Bank charge for warrant 
redemption 

Postage 

Envelope 

Total 



$.02 
.015 

.21 
.0224 
$ .2674 



Currently, the CSC saves only the $0,015 for warrant redemption since a 
deposit notice is still printed (similar to the cost of printing a 
warrant) and sent to all direct deposit obligees If an ARU were made 
available to obligees, they could call to determine if payment had been 
made and may not require a deposit notice. This would allow the CSC to 
realize the full $.2674 savings available. Additional savings of fixed 
expenses and overhead costs could accure as direct deposit volume grows 
substantially. 

The CSC's expenses involved in the direct deposit process include the 
following: 



Tape charges 
Transaction fees 



A maximum of $150 per month 

$.16 per transaction (24-hour turnaround) 



Additional costs are incurred for printing and mailing the applications 
and for staff time for setting up and maintaining the records on the 

system. 

The costs to the CSC for obligee inquiries utilizing an ARU would be as 
follows: 



ARU hardware, software, 
and installation 



none additional to 
obligor-initiated automatic 
withdrawal system 



Monthly licensing and 
maintenance for hardware 
and software 



none additional to 
obligor-initiated automatic 
withdrawal system 



Telephone lines 
(if needed) 

ARU programming and 
voice recording 



$100 each for installation 
$ 50 per month 

$4,000 (approximate) 
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The cost for set up and operation of the ARU would be very small since the 
same ARU could be used for this application as is used for obligor 
initiation of withdrawals from checking. Actual costs and system 
configuration.will depend on the ARU system chosen and the volume of calls 
received. ARU programming costs, based on a rough estimate of 10 
person-days, of work (incremental to development of the obligor-initiated 
withdrawal ARU application), and will vary with the ARU system chosen and 
the complexity of the interface with the ICAR system. 

Additional phone lines may also be required depending on the volume of 
calls received, particularly if all obligees are notified of the ARU 
availability. If more than four telephone lines are used, additional ARUs 
would be required as well. Incremental ARUs could be obtained at a slight 
discount and additional programming effort would be negligible. 

Additional costs will be incurred to make the system changes noted in the 
system specifications section. Internal estimates of the costs are 
needed. System changes were also specified to make possible the 
concurrent automatic withdrawal and direct deposit of payments. ■ These 
will also need to be costed internally. 



CHARGES TO OBLIGOR CREDIT CARD ACCOUNTS 

Prearranged charges to obligor credit cards offer more timely payment for 
the obligee and additional convenience for the obligor. Obligor-initiated 
credit card charges made by accessing an ARU would provide additional 
convenience for the obligor. 

As indicated by the experience of other states, obligors who select this 
alternative are often those with poorer payment records and those who need 
help making the payments. The administrative costs avoided by preventing 
an obligor from going into arrears could help defray the transaction costs 
of this approach. In other words, it is much less expensive to pay the 
credit card fee than to initiate a court action against an obligor who is 
in arrears. 

Charges could be submitted so that the funds are available to the CSC 
precisely on the due date specified by the court order. This would avoid 
the current average delay of about three days when some obligors mail 
their payment on the due date or shortly afterward. 

For the CSC, the pre-authorized credit card process would reduce the 
administrative work of processing and depositing checks, and, with . 
automated transfer of payment information to the ICAR system, eliminate 
the manual entry of information into the payment system or use of the 
remittance processing equipment. 

Initially, when transaction volumes are low, a POS terminal or PC-based 
POS emulation package may be used to initiate transactions. Transaction 
costs for credit card charges submitted in this way would be no more than 
2% of the payment amount. This would yield a charge of $3.00 on a $150 
payment. Additional fees apply to returned items. The cost of the 
terminal or software is typically provided at no charge, as is initial 
training. 
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Staff time would be required for setting up and maintaining the database 
of obligor charges. Additional staff time would be required daily to 
initiate each of the transactions. To the extent that applications for 
credit card payment are not integrated with those for automatic 
withdrawal, additional costs will be incurred for printing and mailing the 
appl ications. .- 

The costs to the CSC office for obligor-initiated charges utilizing an ARU 
would be as follows: 



ARU hardware, software, 
and installation and PC 

Monthly licensing and 
maintenance for hardware 
and software 

Telephone lines 



$30,000 (approximate) 

$300 per month (approximate) 

$100 each for installation 
$ 50 per month 



ARU programming and $4,000 (approximate) 

voice recording 

A separate ARU configuration is necessary for this application since the 
ARU for the obligor-initiated withdrawal and direct deposit/customer 
service inquiry applications interfaces directly with the ICAR system 
rather than a PC. A single ARU can not interface with both a mainframe 
system and a PC. Actual costs and system configuration will depend on the 
ARU system chosen and the volume of calls received. ARU programming 
costs, based on a rough estimate of 10 person-days of work (incremental to 
development of the obligor-initiated withdrawal and direct 
deposit/customer service inquiry ARU applications), and will vary with the 
ARU system chosen and the complexity of the interface with the ICAR 
system. 

Internal costs will also be incurred for the ICAR system modifications 
described in the system specifications section. 
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APPENDIX C / 



APPENDIX D 



D479HS16 



IOWA COLLECTION AND REPORTING SYSTEM 
PAYMENT LOOK UP SCREEN 



ACCOUNT NO 
15033 



PAYOR NO 
52466 



ACCT TYPE 
17 



AMOUNT 



PAYEE : TWILAH HOTOPP 

PAYOR : FRANKLIN T. PUTTS 

132? HARDING 



DES MOINES I A 50314 

EMPLOYER . : PRECISION CLEANING 



OBL . 
TYPE 

CS 

CS 



FREQ 
W 
Ul 



AMOUNT 
35 . 00 
15.00 



EFFECTIVE 
DATE 
07/10/1987 
03/14/1973 



-F5= INQUIRY 

NEXT SCREEN: LOOKUP 



CASE STATUS 

END RECEIPT 
DATE DATE 

07/25/1988 
07/14/1988 
06/30/1983 
06/20/1988 
06/20/1988 
06/17/1988 



NOTES; 
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